I can see how specifying objects instead of raw JSON may be slightly inconvenient, but I don't see how that would limit us from manipulating the data in the ways you specified: we can still split the data or convert it. Additionally, if we actually were storing image paths in a database, it wouldn't really make more sense to reference paths in the repository: we would want to store the actual image externally.

Also, I just found the real reason things broke is since Webpack 5 changed how assets are bundled and I upgraded to react-scripts v5.

Essentially we would ahve to move things around manually. If I wanted to reorganize the way we stored data (say we wanted to regroup certain properties), we have to manually manipulate the code.

I'll give you a concrete example. Let's say we wanted to remove the "links" attribute from events that have no links (i.e. an empty array). I'd much rather write a script to read in the file, edit it, and then save it. Otherwise, we'd have to manually edit the file. This is a basic example since for this, you could probably just cntrl+f and replace but if something takes any more steps, it's easier to manipulate a json file bc you can read it in and edit it.

If you store data in a database, using path references is how we would do it. We would store the images in a storage services like an S3 bin or GCP storage, which would return to us an image url, which we then save in the data base. What I originally meant though was that if we use a database, we could write a script to convert the json data into the database schema so we can automatically populate the data, rather than manual entry.

If the only reason we have to use .js files is to ensure static type checking, then I'd say we're better off implementing TS or some sort of linter. Using js imports seems like a hack that introduces friction. If you're convinced this is better temp solution though, feel free to merge it, otherwise, we can split the webpack change into a separate PR and merge that immediately and leave this for discussion 🧜‍♀️

Sorry, I might have confused this asset issue with some other issue I had a long time ago or something else I was thinking of implementing. Using require does actually provide a compile check. We can keep the JSON data, but there are still other images on the site which should use a static import rather than referencing a path in /public. We might still benefit from reorganizing the merchandise images as I did here since there are some unnecessarily duplicated images.